Description

This PR fixes a swaps token-info navigation bug where tapping the info icon in the token selector could open the wrong asset details screen.

Root cause:

• In BridgeTokenSelector, info-icon navigation used navigate('Asset', params).
• When swaps was entered from an existing asset details route, React Navigation could reuse that existing Asset route instance, resulting in stale params (the entry token) instead of the tapped token.

Fix:

• Switched info-icon navigation to navigation.dispatch(StackActions.push('Asset', params)) so a fresh Asset route is always created with the tapped token params.
• Kept analytics tracking behavior unchanged.
• Updated unit test assertions to validate a PUSH action with correct token params.

Changelog

CHANGELOG entry: Fixed a bug where tapping a token’s info icon in Swaps could open the wrong asset details page.

Related issues

Fixes: SWAPS-4107

Manual testing steps

Feature: Swaps token info navigation opens correct asset details

  Scenario: Open swaps from asset details and inspect another token
    Given I am on any token asset details page
    When I tap "Swap"
    And I open the token selector
    And I tap the info icon for a different token
    Then the asset details page opens for the tapped token
    And not for the original token I started from

  Scenario: Open swaps from a non-asset-details entrypoint
    Given I open swaps from home/wallet actions
    When I open the token selector
    And I tap the info icon for a token
    Then the asset details page opens for that tapped token

Screenshots/Recordings

Before

Behavior reproduced in Jira recording attached to SWAPS-4107 (wrong token details opened).

After

Pending fresh verification recording showing tapped token details open correctly on iOS and Android.

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.